AoAD2 Practice: Stories
この本では、ストーリー＝ユーザストーリー
開発チームで会話をするための仕組み
ストーリー自体は単なるリマインダーにすぎない
オンサイト顧客が優先順位付けできるように使う
技術的な要素はストーリーからは外す
Questions
Our customers understand development. Do we still have to write stories to be customer-centric?
customer-centric stories lead to better plans.
Shouldn’t developers make the software fast by default? Why do we need performance stories?
it just gives you more insight and control over how that time is spent.
「パフォーマンスストーリーにまとめて開発することで、使った時間への示唆とコントロールを与える」
How do we make time for technical infrastructure and large refactorings, such as replacing a test framework?
（技術的な基盤や大きなリファクタリングは）少しずつ増えるようにやりなさい
working incrementally
感想：導入時の「小さく始める」へ通じるかも
Prerequisites
Stories are no replacement for requirements.
詳細化にはストーリーではない別の方法（incremental requirementsなど）
Indicators
ストーリーを上手く使った状態
Stories are cheap to create and easy to discard.
「ストーリは作るのが安価で、捨てるのもたやすい」
Alternatives and Experiments
ストーリーはcustomer-centric
顧客が効果的に計画づくりに参加するため
誰しもがストーリーに一家言ある
Stories are about the conversation,
writingよりもtalkingを重視
ビジネス理解を最初にして、決定をしてから、ストーリー（リマインダー）を使う
ジェフ・パットン「ストーリーは休暇の写真（vocation photo）」
リマインダーの喩え
Make the vacation better, not the photo.
putting more emphasis on the conversation
大事なのはストーリーではなく、それをもとに開発チームで話すこと
スプレッドシートやIssue管理ツールはストーリーの追跡には向かない
story cards aren’t miniature requirements documents.